It is often the case that the symptoms of a machine failure indicate a number of alternative explanations. Usually it is more cost effective and less time consuming to observe the machine in more detail in order to rule out some of the alternative explanations. The process of iteratively observing the machine and ruling out potential causes of machine failure is called "failure isolation".
Failure isolation can be performed manually with the aid of a fault tree, a flowchart-like representation of the iterative observation/elimination steps of failure isolation. Each element of the fault tree requests a user to make a particular observation. Extending from each element is a plurality of branch paths, each of which leads to a different portion of the fault tree. The user follows a particular branch path based on the results of the observation requested by the current element. At some point in the process, the user will reach an element, having no branches extending therefrom, indicating the particular component or group of components which has failed.
For very large and complex machines, a fault tree can run on to many pages and perhaps to multiple volumes, thereby rendering the fault tree difficult to traverse. One solution is to use a computer having therein a rule-based failure isolation system, a program that contains the information from the fault tree. The computer directs the user to make observations and enter the results.
However, for both a fault tree and for a rule-base failure isolation system, all of the possible failure modes which a user may encounter need to be determined at the time of creation. While this may not be difficult for simple machines, it may be impossible or at least extremely impractical for more complex machines. It is not uncommon for either a fault tree designer or a rule-based failure isolation system programmer to omit some of the failure modes of a machine. This omission is either inadvertent due to the enormity of the task or is an intentional decision to maintain the size below a practical limit.
A solution to the inability of either faucet trees or rule-based failure isolation systems to isolate every conceivable failure can be found in Davis, Randall "Diagnostic Reasoning Based on Structure and Behavior", Artificial Intelligence, 24 (1984), 347-410. Davis proposes a failure isolation approach called "constraint suspension", wherein a computer generates a plurality of models of the machine. Each of the models assumes a different failed component or group of failed components. The model which most closely resembles the observations of the user indicates which component or group of components have failed.
A drawback to the constraint suspension technique is that modeling complex machines having many analog quantities is very processor intensive and the amount of time it takes to run the system becomes prohibitive. A solution to this is found in a paper, "HELIX: A Helicopter Diagnostic System Based on Qualitative Physics", Hamilton, Thomas P., International Journal of Artificial Intelligence in Engineering, Vol. 3, No. 3 July, 1988, pp 141-150. Hamilton suggests coupling constraint suspension with qualitative physics, a modeling technique wherein analog quantities are represented as variables which can take on a finite set of values. Each of the finite qualitative values represents a different range of the analog quantity. However, the Hamilton paper does not contain sufficient detail to enable one skilled in the art to make and use a qualitative physics failure isolation system.